Generally speaking, implementation is performed on the entire integrated circuit (IC) design in a typical IC design flow to turn a logical representation of the design into a physical representation of the design. In the current document, the entire design of a semiconductor IC is referred to as a full-chip design. Boundary can be defined within the full-chip design to divide the full-chip design into a number of regions, each containing a set of circuit objects (which are simply referred to as objects hereinafter). When these regions are still logically connected to each other in the full-chip design, these regions are referred to as partitions of the full-chip design. But when these regions are logically separated or cut from each other such that each region becomes an individual entity, each of these regions is referred to as a block.
A flow diagram describing one conventional process to implement a full-chip design is illustrated in FIG. 1A. Note that the conventional process in FIG. 1A may be referred to as a top-down design approach. At processing block 110, the full-chip design is read in. Then the full-chip design is flattened in processing block 120. At processing block 130, the boundary of a set of partitions in the full-chip design is defined.
After defining the boundary, full-chip placement, routing, timing analysis, and optimization are performed on the full-chip design at processing block 140. In other words, the above operations are performed on a variety of objects (e.g., pins, ports, cells, nets, clocks, etc.) in each of the partition in the full-chip design. Then the design is cut into blocks at the boundary at processing block 150 to derive block constraints and pin assignment. The cutting of the full-chip design into blocks may be referred to as partitioning. Each of the blocks is a separate individual entity. Using the results from processing blocks 140 and 150, timing models of the blocks can be created. These models of the blocks may be merged or integrated to generate a new top view of the full-chip design. Integration of the models of the blocks is possible if the implementation of each block can meet the block constraints derived during the cutting at processing block 150.
However, the conventional process described above usually takes a long time to run. The processing time increases as the size and complexity of the IC design grows. Given that design netlists today are approaching fifty million instances, processing time has become an increasingly more important issue in IC design flow. In particular, timing analysis typically takes longer to run than other operations performed during full-chip implementation (e.g., placement, routing, optimization, etc.). In general, all objects in the partitions of the full-chip design are processed to create the timing models for the timing analysis. However, it is unnecessary to process many of the objects in order to provide accurate timing analysis. Therefore, much of the processing time and memory capacity have been wasted in processing all objects in the partitions of the full-chip design.
In order to improve the speed of design implementation and to reduce the memory capacity required, some techniques have been developed. One such conventional technique is to cut the full-chip design into blocks, derive Interface Logic Models (ILMs) of the blocks, and perform timing analysis on the ILMs. FIG. 1B illustrates a flow diagram of one conventional process to derive an ILM for a block.
Referring to FIG. 1B, the internal timing on the block is verified at processing block 160. By ensuring that the internal register-to-register paths on the block meet timing requirements over a narrow timing range for global chip-level signals, such as clocks, reset, scan enable, etc., the verification results for the internals of the block are valid as long as these global chip-level signals conform to their expected timing.
At processing block 165, the interface logic of the block is identified based on the connectivity of the objects in the block. According to one conventional approach, three types of objects are identified to be the interface logic of a block. First, all objects contained in timing paths leading from input ports to either an edge-triggered register or output ports at which these paths terminate are identified as interface logic. Second, all objects contained in timing paths leading to output ports from either edge-triggered registers or input ports at which these paths originate are also identified as interface logic. Third, the clock tree that drives interface registers is identified as interface logic as well.
After identifying the interface logic of the block, a netlist is written for the ILM of the block at processing block 170. Note that the ILM netlist includes only the identified interface logic. Objects not identified as interface logic at processing block 165 (also referred to as the internal logic or the core logic of the block) are not included in the ILM netlist. The unidentified objects are removed (also referred to as trimmed). As a result, the ILM derived contains fewer objects than the original block. According to one conventional approach, a flattened Verilog netlist is generated for the ILM. The flattened Verilog netlist does not preserve any of the original design hierarchy.
At processing block 175, the ILM constraints are written. The ILM constraints include assertions and exceptions that apply to the objects that belong to the ILM. Note that the ILM constraints may be flattened if the ILM netlist is also flattened.
Finally, ILM back-annotation files are written at processing block 180. In general, the back-annotation file associates some or all of the objects within the block with their corresponding resistive and capacitive parameters. The back-annotation files written may contain only information for the pins and nets that belong to the ILM.
Timing analysis is then performed on the ILM generated. Since the ILM contains significantly fewer objects than the original block does, timing analysis can be performed faster on the ILM than on the original block, and hence, reducing the time it takes to run full-chip implementation. However, one drawback of the approach using the ILM is that the ILMs cannot be merged back for other operations performed during full-chip implementation (e.g., placement, routing, optimization, etc.) because the internal logic of the blocks have already been removed from the ILMs of the blocks. In general, many operations of the full-chip implementation are performed on both the interface logic and the internal logic of the blocks. Thus, the ILMs are essentially useful only for timing analysis in the typical full-chip implementation process.